Designing and fabricating electronic systems typically involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of electronic system to be manufactured, its complexity, the design team, and the fabricator or foundry that will manufacture the electronic system from a design. Typically, software and hardware “tools” verify the design at various stages of the design flow by running simulators and/or hardware emulators, or by utilizing formal techniques, allowing any errors in the design discovered during the verification process to be corrected.
Initially, a specification for a new electronic system can be transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the electronic system. With this logical design, the electronic system can be described in terms of both the exchange of signals between hardware registers and the logical operations that can be performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as System Verilog or Very high speed integrated circuit Hardware Design Language (VHDL).
The logic of the electronic system can be analyzed to confirm that it will accurately perform the functions desired for the electronic system, sometimes referred to as “functional verification.” A design verification tool can perform functional verification operations, such as simulating, emulating, and/or formally verifying the logical design. For example, when the design verification tool simulates the logical design, the design verification tool can provide transactions or sets of test vectors, for example, generated by a simulated test bench, to the simulated logical design. The design verification tool can determine how the simulated logical design responded to the transactions or test vectors, and verify, from that response, that the logical design describes circuitry to accurately perform functions.
The design verification tool also can quantify how well the test vectors input to a logical design under verification came to covering or adequately exercising the logical design. For example, the design verification tool can record when certain portions of code for the logical design were executed during functional verification of the logical design. Traditional code coverage identifies which portions of the logical design under verification were utilized or exercised, while those portions were in a normal operational state or a normal power mode.
Many of today's electronic systems are designed to be power efficient, and thus may have multiple different power domains, each of which can have multiple different power modes. The different power modes for the different power domains can have functional dependencies in the logical design. For example, a functionality of the logical design and associated electronic system can change based on power mode, such as when portions of the logical design have a power mode that renders those portions not fully operational. In some instances, the power modes can cause structural changes in the logical design under verification by introducing new objects or hierarchies in the logical design. The power modes also can cause behavioral changes in existing combinatorial and/or sequential blocks. Since conventional design verification tools ignore collecting coverage events for operations of the logical design while in non-normal power modes, verification engineers have a difficult time determining whether functional verification operations exercised the logical design while in the different power modes and associated operational states for the electronic system.